The ATAM session was for our part somehow amputated. Not every member, on both teams, had attended the lecture on ATAM, and were not properly introduced to the process so a minor prestudy-session was included. The other groups documentation was well written and we did not have any big problems in understanding it. Both groups read through each others documentation and explained the things that were diffuse. 


Following the prestudies, we approached the step-by-step process of an ATAM evaluation. Steps 1 through 4 (introduction and presenting of business drivers and architecture, identification of architectural approaches) was walked through fairly quickly. Step 5, generating quality attribute utility tree, proved to be more problematic. However, with assistance we managed to understand this step. In the analyzing of architectural approaches (step 6) we used the template and analyzed each approach accordingly. 


For our evaluation, step 6 seemed to be the most useful. However, our evaluation did not influence too much change in the architecture. In addition to the analyze of the existing tactics included, we proposed for the other group to incorporate the abstract factory pattern, a seemingly well-received proposition, which was the only change following the evaluation.


The evaluation of our group did not prove to be that helpful. The evaluation did include some feedback such as the identification of pros and cons of each architectural tactic, but it did not lead to any major change in our systems architecture.  


Overall the ATAM process has its benefits. The main benefit is to get another perspective on the architecture, and this may include important inputs on how to move the architectural design in the right direction. However, since our project is rather small in size, in addition to having no earlier experience with ATAM, the evaluation did not prove to be that useful. The reason being that we did not alter our architecture in any significant way following the evaluation. 
